In the modern software industry, software program vendors suffer huge losses due to the illegal distribution of software programs, a practice known commonly as software piracy. Part of the problem of software piracy is due to the fact that software programs, distributed as electronic files, are vulnerable to modifications by users. Thus, even those software programs that enforce online registrations prior to their legal use as a means of preventing unauthorized use can be modified by a malicious user (a “hacker”) to bypass the online registration process. Such compromised software programs can be massively duplicated and distributed, particularly in countries that do not provide the same legal protections to copyright owners as are found under United States law, and also in countries where software program vendors have less control over their products. As a result, software copyright owners lose significant revenue from lost sales and the development of competitive programs based on pirated copies of the copyrighted software.
It is known in the art to embed security mechanisms in the software program code in an attempt to hinder the efforts of hackers. One such mechanism well known in the art is to require the initial user to input a serial number into the software program prior to the initial use of the software program. The software program then will apply this serial number to an embedded algorithm to compute the true serial number of the software program, thereby validating the authenticity of the software program copy. This type of embedded security mechanism and others like it are vulnerable to compromise because such mechanisms often are based entirely on a few machine instructions within the software program. For example, many software programs use only a single instruction, typically a conditional jump, to compare the serial number entered by the initial user with the serial number computed by the software program to determine whether the software program copy is authentic. The use of a single instruction for this important security step provides the hacker with a single point of attack to defeat the security mechanism. To defeat such a mechanism, the hacker merely needs to find the conditional instruction in the code and replace it in the binary file with an unconditional instruction that advances the execution flow of the software program to the desired location, bypassing the serial number comparison step. Another approach employed by hackers to defeat such a security mechanism is to insert a sequence of small null operations that do nothing except advance the execution flow of the software program to the desired location naturally. Either kind of modification allows illegal software program users to freely run the compromised software programs.
There are several more advanced security mechanisms known in the art, but their results and applicability have not been promising to the software industry. One such advanced security mechanism uses special hardware that directly executes an encrypted software program without the software program's underlying binary code ever being disclosed in memory. The details of this method are disclosed in U.S. Pat. No. 4,465,901 to Best. Further disclosure of a similar method is made by White et al. in an article entitled “ABYSS: An Architecture for Software Protection,” published in IEEE Transactions on Software Engineering, 16(6):619-629, June 1990. While this approach solves the problem, it has a major disadvantage in that encryption keys and special hardware are required for encrypting and executing the software program. Because of the need for encryption keys and special hardware, the result is a security mechanism that is more expensive and provides less user flexibility than a security mechanism which relies entirely on software-based techniques.
Another security mechanism known in the art is the use of code obfuscation, which makes the code difficult for a hacker to understand and analyze. Methods of code obfuscation are disclosed by Collberg et al. in an article entitled, “Breaking Abstractions and Unstructuring Data Structures,” published in IEEE International Conference on Computer Languages, ICCL'98, Chicago, Ill., USA, May 1998; by Collberg et al. in an article entitled, “A Taxonomy of Obfuscating Transformations,” published as Technical Report 148, Department of Computer Science, The University of Auckland, Private Bag 92019, Auckland, New Zealand, 1998; by Bashar et al. in an article entitled, “Low-Threat Security Patches and Tools,” published as Technical Report CSD-TR-96-075, Coast TR 97-10, COAST Laboratory, Department of Computer Sciences, Purdue University, 1996; and by Mambo et al. in an article entitled, “A Tentative Approach to Constructing Tamper-Resistant Software,” published in New Security Paradigms Workshop. Proceedings, pages 23-33, New York, N.Y., USA, 1998. Unfortunately, techniques currently known in the art of code obfuscation still are not adequate to prevent sophisticated software program hackers from identifying and modifying attack targets in the code.
Joepgen et al. disclose in their article entitled, “Software by Means of the ‘Protprog’ Method, Part II” published in Elektronik, 42(17):52-56, August 1993, a security mechanism utilizing “self-modifying code,” wherein the software program code generates other code at run-time.
Schulman discloses in his article entitled, “Examining the Windows AARD Detection Code,” published in Dr. Dobb's Journal, 18(9):42,44-8,89, September 1993, another security mechanism utilizing code encryption and decryption, wherein partially encrypted code self-decrypts at run-time.
Aucsmith discloses in his article entitled, “Tamper Resistant Software: An Implementation,” Ross Anderson, editor, published in Information Hiding—Proceedings of the First International Workshop, volume 1174 of LNCS, pages 317-333, May/June 1996, yet another security mechanism which utilizes a hybrid of the self-modifying code technique and the code encryption/decryption technique. U.S. Pat. No. 5,892,899 to Aucsmith et al. discloses a similar mechanism.
Several disadvantages are present in the prior art security mechanisms. First, the mechanisms which utilize self-modifying and self-decrypting code produce an extra burden on the computing resources at run-time. Second, the Integrity Verification Kernels (“IVK”) disclosed by Aucsmith in his article are relatively large segments of code. Because the IVKs must be decrypted during program execution and then subsequently encrypted, the program execution performance degrades. In addition, the design of Aucsmith's IVKs make the IVK concept difficult to apply to larger IVKs. The processing time involved in decrypting and encrypting the larger IVKs may degrade program execution performance to the point where it is intolerable to the end-user. Furthermore, the first cell of each IVK is unencrypted. The large size of the IVKs and the presence of the unencrypted first cell may provide clues to a hacker as to the location of the security mechanism within the code. Third, the security mechanism disclosed by Aucsmith in his article requires special services from the operating system software for proper execution. The resultant interaction between the security mechanism and the operating systems software may direct a hacker to the location of the security mechanism or to sensitive areas of the code. Finally, most prior art security mechanisms produce immediate program execution failures upon tampering. Such immediate failures provide additional clues for hackers as to the location of the security mechanisms or the sensitive areas of the code.
Thus, such prior art software security mechanisms tend to be restricted in their applicability, and they have not been widely adopted by the software industry. It is desired in the software industry to develop a method for protecting a software application program from unauthorized modification which will not require special hardware, self-modifying code, or code encryption and decryption. It is further desired that the method will not require special operating system services and that the method will produce subtle errors rather than immediate program failure.